The mobility management serving node pool, such as a Serving GPRS Support Node (SGSN) pool, a Mobility Management Entity (MME) pool, is to provide network redundancy for failure handling, planned maintenance without service downtime, easy network expansion, reduced network signaling load, a higher capacity usage ratio and load re-distribution within the pool.
When re-balancing a pool, e.g. in order to (re)-populate a node taken into service, it is necessary to get an even distribution of moved subscribers with respect to end-user behavior. This is essential not to create a skewed distribution within the pool and as a consequence subscribers running payload should be possible to move. The load re-balancing may off-load part of or all the subscribers.
During moving operations, the pool node (such as a SGSN in the SGSN pool, or a MME in the MME pool) may offload its subscribers with minimal impacts on the network and users, e.g., the pool node should avoid offloading only the low activity users while retaining the high activity subscribers. Gradual rather than sudden off-loading should be performed as a sudden re-balance of a large number of subscribers may overload other pool nodes in the pool. With minimal impact on network and the user's experience, the pool node should be off-loaded as soon as possible.
Conventionally moving subscribers within the mobility management serving node pool (SGSN or MME pool) is only possible by using a detach/reattach procedure (with a reattach flag) or by using the Routing Area Update (RAU)/Tracking Area Update (TAU) procedure which is stipulated by 3rd Generation Partnership Project (3GPP).
Nonetheless, this results in a drawback for the end-user that significant interruption/loss of payload would possibly happen.
Additionally, eNodeBs may have their load balancing parameters adjusted beforehand (e.g. the Weight Factor is set to zero if all subscribers are to be removed from one MME, then new entrants into the pool area will be routed to other MMEs). The MME initiates a S1 Release procedure with a release cause “load balancing TAU required”. The S1 and RRC connections are released and the UE initiates a TAU but does not provide registered MME information to eNodeB in the RRC establishment, thus the eNodeB has to select an MME based on the Weight Factors of the MMEs in the pool.
This causes another problem that when re-balancing the MME pool, the re-balance is still dependant of eNodeB Load Balancing factor. It can not secure that the re-balance result is what is intended to achieve.
To this end, an improved procedure of moving subscribers within a mobility management serving node pool for addressing at least one of the above problems, such as without significant service interruption/loss and/or securing the re-balance effect, is therefore highly desired.